1. Technical Field
The present invention relates generally to authenticating a user of a client machine running a native operating system against a user account held at a native and/or non-native server domain.
2. Description of the Related Art
The client-server model of computing is a well-known environment. In the model, the user of a computer utilizes a xe2x80x9cclientxe2x80x9d system. The client system runs any of a number of computer operating systems to manage the basic functions that users execute (such as accessing files, executing programs, system administration and the) as well as to serve as the base against which programs are written. Well-known client operating systems include (Microsoft Windows 3.1), Windows for Workgroups, Windows 95, IBM(copyright) OS/2(copyright) Warp, Apple Macintosh, DOS, manyvariations of UNIX, and Microsoft Windows NT. The client system serves as the user""s workstation, and it may execute programs as well as store some user data.
The server system can also run any of a number of computer operating systems. Well-known server operating systems include Novell Netware, IBM OS/2 Warp Server, IBM AS/400(copyright), Microsoft Windows NT, and many variations of OSF UNIX. The server system is accessed by the client system for specific functions. The functions include, but are not limited to, storage and retrieval of data, storage and execution of applications, and storage of and access to user information.
Industry standards have been developed (for critical and common functions) to aid in the access from different types of client systems to different types of server systems. The use of these standards on the client and server afford users the opportunity to carry out functions in a consistent manner on a variety of common client and server operating systems. One of the activities that has been standardized is the xe2x80x9cauthenticationxe2x80x9d of users. Authentication refers to the process in which a user is validated as being able to complete a logon and/or access a system. Standard protocols have been defined within the x/open Server Message Block (SMB) specification and the Open Systems Foundation (OSF) Distributed Computing Environment (DCE) specification.
While many products and operating systems have been developed that utilize the standard protocols, not all products have used the standards. When this occurs, either additional work must be done by the other operating system to implement the unique commands used by a vendor, or access to the other new system and/or product is not allowed if the unique commands are not made available to other vendors. When the commands and/or protocol are not made available, that aspect of the system and/or product is sometimes characterized as being xe2x80x9cclosedxe2x80x9d.
The Microsoft Windows NT operating system is becoming a dominant client system in many enterprise computer networks. Because of the xe2x80x9cclosedxe2x80x9d nature of Windows NT, a user of a client machine running this operating system may only log on against an account held at the machine, at a server running the Windows NT operating system, or at any other servers that are xe2x80x9ctrustedxe2x80x9d by the NT server that the client is configured against. Only these options are supplied to the user during the logon process, and there are presently no documented interfaces to allow user authentication from (a) other native server domains against which the client has not been previously configured, or (b) non-native server domains. Thus, the NT user account required for initial authentication may exist only on an NT client or in an original NT server domain. This closed architecture eliminates the ability to do full centralized administration from alternative sources, such as other NT domains or other non-native domains.
Therefore, there remains a need in the art to xe2x80x9copen upxe2x80x9d Windows NT clients to authentication from a wider set of choices and, as a corollary, a need to provide some mechanism to assist in discovering and managing these choices. Moreover, many system administrators desire increased system capabilities while having tools to control what capabilities are presented to end users.
The present invention addresses this problem.
It is a primary object of this invention to allow an administrator of a client system to manage xe2x80x9cdiscoveredxe2x80x9d authentication server domain information.
It is another object to provide a mechanism by which an administrator of a client system may configure discovery policy for that system.
It is another primary object to discover and manage information about foreign authentication providers in a closed client/server network environment.
Yet another important object of this invention to discover and manage information about native and/or non-native server domains to facilitate user authentication in a computer network.
It is a more specific object of this invention to enable an administrator to discover and manage information about native and/or non-native authentication domains that might then be selected by a user for authentication.
Still another primary object of the present invention to provide a mechanism for managing server domain authentication information according to one or more xe2x80x9cpolicies.xe2x80x9d Thus, for example, the policy control may dictate whether a user seeking logon can force discovery of domains, or whether a user may enter a given location at which the user desires to be authenticated. The interface is xe2x80x9copenxe2x80x9d to allow for additional policies to be implemented.
Thus, a more general object of this invention is to allow an administrator of a client system to set one or more policies that control domain information discovery on the particular system.
A more specific object of this invention is to allow discovery and management of Windows NT server domain information in conjunction with Windows NT client authentication.
In the preferred embodiment, the client machine runs the Microsoft Windows NT operating system and authentication may be effected from one or more non-native server domains including, without limitation, a Server Message Block (SMB) server domain, a DCE Cell, or some other non-Windows NT server domain. The various native and/or non-native server domains are xe2x80x9cdiscoveredxe2x80x9d by issuing requests from the client to one or more of the servers in the network. Each response is then characterized as being from a native or non-native server, and a list of each such server type is then compiled at the client. The administrator may modify the discovered information and/or apply a discovery xe2x80x9cpolicyxe2x80x9d to tailor the way in which a user may access and interact with the discovered information.
Thus, for example, the administrator may add and remove authentication locations that were discovered by the client system before these locations are presented to the user seeking authentication. The administrator may also enter an authentication location to ensure it is presented to the user. This location may be a Windows NT server domain name, a SMB server domain name, or a DCE Cell name. Discovery policies may then be used, for example, to determine whether users can type in their own authentication location names or to select whether a given user can initiate his or her own discovery. The interface is open to implementation of other discovery policies as desired to provide a robust and efficient discovery management tool.
The foregoing has outlined some of the more pertinent objects and features of the present invention. These objects should be construed to be merely illustrative of some of the more prominent features and applications of the invention. Many other beneficial results can be attained by applying the disclosed invention in a different manner or modifying the invention as will be described. Accordingly, other objects and a fuller understanding of the invention may be had by referring to the following Detailed Description of the Preferred Embodiment.